home *** CD-ROM | disk | FTP | other *** search
- Path: mail2news.demon.co.uk!genesis.demon.co.uk
- From: Lawrence Kirby <fred@genesis.demon.co.uk>
- Newsgroups: comp.lang.c
- Subject: Re: Undefined behavior? on type conversion, was: Re: Hungarian notation
- Date: Mon, 29 Jan 96 23:23:00 GMT
- Organization: none
- Message-ID: <822957780snz@genesis.demon.co.uk>
- References: <30C40F77.53B5@swsbbs.com> <4d2ok0$69s@beach.and.nl> <KANZE.96Jan24152858@slsvewt.lts.sel.alcatel.de>
- Reply-To: fred@genesis.demon.co.uk
- X-NNTP-Posting-Host: genesis.demon.co.uk
- X-Newsreader: Demon Internet Simple News v1.27
- X-Mail2News-Path: genesis.demon.co.uk
-
- In article <KANZE.96Jan24152858@slsvewt.lts.sel.alcatel.de>
- kanze@lts.sel.alcatel.de "James Kanze US/ESC 60/3/141 #40763" writes:
-
- (Newsgroups trimmed)
-
- >Does it? I believe that it was the intent of the authors that the
- >`result' of the conversion could be a signal (for example) or a core
- >dump.
-
- I disagree!
-
- > (This is, of course, the only reasonable thing for an
- >implementation to do.)
-
- Possibly but existing practice won out here. The normal approach is for the
- compiler to pick ot the relevant low order bits and ignore the higher order
- ones. That also has the effect of preserving value in a
- signed->unsigned->signed conversion although the standard gives no guarantees
- about this which leaves a problem with char handling: can you portably assign
- the return value of getchar() (non-EOF values can be represented in an
- unsigned char) to a char which may be signed?
-
- --
- -----------------------------------------
- Lawrence Kirby | fred@genesis.demon.co.uk
- Wilts, England | 70734.126@compuserve.com
- -----------------------------------------
-